1. Field of the Invention
The present invention relates to clusters of nodes included in computer networks and, in particular, to uniquely identifying entities included in such clusters.
2. Description of Related Art
In computer networks, nodes may interact through requests for data, services, or other resources. Client nodes may generate requests and server nodes may service those requests. Nodes may be stand-alone computers, servers, or other computing devices as well as virtual machines. Nodes may be grouped into clusters to provide heightened availability and/or scalability when servicing client requests.
External client nodes may view a cluster as a single entity. Accordingly, communications between an external client and a cluster typically include an ID that identifies the external client node and a node within the cluster. The node in the cluster with which the client is communicating is typically not identified, however. For example, in a cluster of web servers, each computing machine in a TCP/IP network has a unique IP address. When a user requests a URL via a web browser, directory and/or naming services provide an IP address of a server, which is used to establish a connection with that server. However, each server in a cluster has a unique IP address, so it is difficult to provide a single URL that maps to all of the servers in the cluster.
One existing solution to this addressing problem uses an intelligent naming service, such as a hybrid DNS server, that associates a name with a set of IP addresses representing the addresses of all the servers in the cluster. However, naming services are typically unable to make sophisticated decisions about which IP address to return at any given time. For example, a naming service is typically unaware of the number of open connections at each node, and thus cannot select an IP address in order to improve load balancing. Naming services are also typically unaware about factors such as the functionality provided by each server and/or the location of each server, and thus cannot additionally optimize selection of which IP address to return based on these factors. An alternative approach returns the IP address of a “gateway” node for a particular URL. The gateway node may select another cluster node (e.g., based on location, functionality, load, etc.) to which a particular client request should be redirected.
As the above examples show, the inability to directly identify a cluster (as opposed to a particular node) within a client request may complicate the routing of client requests to, from, and within a cluster. When a node fails, communication within the cluster may be further aggravated. For example, if a client established a connection with a node that subsequently fails, a client communication sent to the node after the node's failure may not provide enough information to easily redirect the client communication to another node within the cluster. Instead, the entire address translation process may have to begin again. Furthermore, in many situations, only certain nodes within a cluster may have copies of data needed to respond to the client request. Accordingly, rerouting a client request due to the unavailability of the original cluster node may additionally be complicated by the distribution of data within the cluster.
Another problem in communicating within a cluster is that existing solutions often fail to uniquely identify entities (e.g., processes or applications) within a cluster. This may additionally complicate routing when entities fail. Thus, it is desirable to distinctly identify clusters and entities within clusters in order to more efficiently route client communications both within and between nodes.